Streaming or media streaming is a technique for transferring data so that it can be processed as a steady and continuous stream. Hence, streaming media is multimedia (e.g. audio and/or video) that is constantly received by and presented to an end-user while being delivered by a provider. “Stream”, refers to the process of delivering media in this manner; the term refers to the delivery method of the medium rather than the medium itself.
By using streaming, the client (browser) can start displaying the received media data before the entire file has been transmitted. However, if the streaming client receives the media data more quickly than required, it needs to save the excess media data in a buffer. When the media data to be streamed comprises video pictures, the video pictures can be encoded as P, B, and I frames.                I-frames are the least compressible but don't require other video frames to decode and are also referred to as key frames. In order to be able to start decoding, a key frame is required.        P-frames requires data from previous frames to be decodable.        B-frames requires previous and/or forward frames to be decodable.        
It should be noted that P- and B-frames can be compressed to a much larger extent than the key frames.
Adaptive bitrate streaming is used for multimedia streaming. Many adaptive streaming technologies are based on HTTP (Hypertext transfer protocol) and designed to work efficiently over large distributed HTTP networks such as the Internet.
Adaptive bitrate streaming works by detecting a user's bandwidth and/or other relevant parameters such as CPU capacity, hardware decoding capacity etc. in real time and adjusting the quality of a video stream accordingly. It requires the use of an encoder which can encode a single source video at multiple bit rates. The streaming sent to the player client switches between the different encodings depending on available resources. This results in little buffering, fast start time and a good experience for both high-end and low-end connections.
An example of an implementation is adaptive bitrate streaming over HTTP where the source content is encoded at multiple bit rates, and each of the different bit rate streams are segmented into small multi-second parts. This is illustrated in FIG. 1A. The streaming client is made aware of the available streams at differing bit rates, and segments of the streams by a manifest file. When starting, the client requests the segments from the lowest bit rate stream. If the client finds the download speed is greater than the bit rate of the segment downloaded, then it will request the next higher bit rate segments. Later, if the client finds the download speed for a segment is lower than the bit rate for the segment, and therefore the network throughput has deteriorated, then it will request a lower bit rate segment. The segment size can vary depending on the particular implementation, but they are typically between two and ten seconds.
When changing from a first channel (i.e. a first stream) to a second channel (i.e. a second stream), the client must await a key frame in order to be able to decode the second channel.
For example, in the DASH (Dynamic Adaptive Streaming) standard, there can be 5 seconds segments in different bitrates, where each segment starts with a key frame (i.e. an I frame) and the following frames are P- or B-frames.
That can be exemplified by:
NormalA: 5-seconds @2 Mbit/s=10 Mbit
NormalB: 5-seconds @1 Mbit/s=5 Mbit
NormalC: 5-seconds @0.5 Mbit/s=2.5 Mbit
NormalD: 5-seconds @0.25 Mbit/s=1.25 Mbit
An intune track is also provided, which comprises multiple I-frames, e.g. one I-frame per second. The intune track can be provided in different bitrates.
Assume that the intune track is only provided in the lowest bitrate:
IntuneD: 5-seconds @0.25 Mbit/s=1.25 Mbit
The “IntuneD” has many I-frames which results in that the quality is lower than for NormalD even though they have the same bitrate. There is also a manifest file which provides information on the different available files including the position of the I-frames.
Thus, the manifest file can include the following information:
IntuneD: Iframes: 0 bits (0 s), 250000 bits (1 s), 500000 bits (2 s), 750000 bits (3 s), 1000000 bits (4 s)
If a user wants to join a channel at t=3.75 seconds. The user performs a http-get on the manifest file and then gets information that there is an Intune file, IntuneD (with 5 seconds). The user then performs a http get on IntuneD but with a bit range of 1000000-1250000. That implies that the user will only get the last second of the file. The user will suffer from a 0.25 seconds delay. Although the amount of data is exemplified in the number of bits in this example, it should be noted that the manifest file usually defines the amount of data in bytes.
However, this procedure requires functionality by the client.